home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Columbia Kermit
/
kermit.zip
/
newsgroups
/
misc.19980424-19980901
/
000121_news@newsmaster….columbia.edu _Sat May 23 05:02:19 1998.msg
< prev
next >
Wrap
Internet Message Format
|
2020-01-01
|
6KB
Return-Path: <news@newsmaster.cc.columbia.edu>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id FAA27908
for <kermit.misc@watsun.cc.columbia.edu>; Sat, 23 May 1998 05:02:18 -0400 (EDT)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id FAA19431
for kermit.misc@watsun; Sat, 23 May 1998 05:02:18 -0400 (EDT)
Path: news.columbia.edu!panix!howland.erols.net!Supernews73!supernews.com!nntp.flash.net!scanner.worldgate.com!rover.ucs.ualberta.ca!news.ucalgary.ca!acs2.acs.ucalgary.ca!mmastrac
From: Matthew Mastracci <mmastrac@acs.ucalgary.ca>
Newsgroups: comp.protocols.kermit.misc,comp.sys.hp48
Subject: Re: Kermit on the HP48 (Was: One-Way Transfer)
Date: Sat, 23 May 1998 02:13:14 -0600
Organization: The University of Calgary
Lines: 102
Message-ID: <6k60eq$cva@ds2.acs.ucalgary.ca>
References: <35646665.EBB3868B@theriver.com> <6k1qoj$d92$1@apakabar.cc.columbia.edu> <wkvhqye9g4.fsf@jhuapl.edu> <6k42pd$a3m$1@apakabar.cc.columbia.edu>
NNTP-Posting-Host: mmastrac@acs2.acs.ucalgary.ca
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
To: Frank da Cruz <fdc@watsun.cc.columbia.edu>
In-Reply-To: <6k42pd$a3m$1@apakabar.cc.columbia.edu>
Xref: news.columbia.edu comp.protocols.kermit.misc:8776 comp.sys.hp48:81349
On 22 May 1998, Frank da Cruz wrote:
> As noted in an earlier posting in this thread, I would like to straighten
> out the massive confusion about Kermit file transfer with the HP-48. We (at
> the Kermit Project) are not HP-48 experts, but we do have an early model
> HP-48 for testing. When we get complaints or questions about file transfer
> with the HP-48, we check our answers on it.
I've written a Kermit program for transferring between the PC and the
HP48, so I'd like to offer my discoveries (I've spent a long time getting
my client to connect to the calculator).
> 1. The top serial speed is 9600, right?
Yes.
> 2. Should the flow control setting be NONE or XON/XOFF? We have
> conflicting reports (see above). Obviously the HP-48 *should* be
> exercising some form of flow control, but some reports indicate that
> it does not (even if it is set to do so).
The calculation doesn't need flow control, as the size of a packet will
never exceed the internal buffer (sliding windows aren't supported).
Having XON/XOFF interferes with the transfer, from what I can tell, as the
HP48 picks the control characters up as unquoted data. I can tell you
*absolutely* that flow control is not required.
> 3. Is the link transparent to incoming control characters? Can the
> client Kermit program use control-character unprefixing when sending
> to the HP-48? If not, the client program must be told to
> SET CONTROL PREFIX ALL prior to sending files to the HP-48.
The link is transparent to all characters. The HP48 will reject any
packet that contains an unquoted control character with a NAK packet (this
is probably because the calculator can also send via IR, which may
introduce errors). Control-character prefixing must be used to send to
the HP48.
> 4. Does the link allow 8-bit data? If not, the client must be given
> the appropriate SET PARITY command.
The default setting for the HP48's serial port is 9600 baud, no parity, 8
bits and 1 stop bit. If it has been set to something else, you can
restore it to this default by deleting the IOPAR variable.
> The HP-48 does not support long packets; thus the maximum packet length
> is 94, but this should be negotiated automatically.
This is negotiated properly.
> The HP communication port is half duplex, meaning that data can go in both
> directions, but only in one direction at a time. Therefore sliding windows
> can not be used (this too should be negotiated automatically).
Yes. The HP48's info is something like "~* @-#N1".
> More to the point, I have also heard that (at least some models of) the
> HP-48 become "deaf" to incoming bytes for some number of milliseconds while
> switching their serial port from "send" to "receive", so if the client
> program is too fast, file transfers can fail. The solution to this is to
> tell the client program to pause for a sufficient number of milliseconds
> prior to sending each packet:
This only happens every dozen packets or so. A client that can resubmit a
NAK'd packet will be able to recover from this. If you watch a transfer
at high speeds, you'll see every few packets fail (for no apparent reason:
the link cable is a very clean line). Setting the flag you mentioned will
fix the problem.
> Postings on comp.sys.hp48 indicate that the HP-48 Kermit implementation
> "parses" incoming text-mode material on the fly, and appends the material
> from each incoming packet to a "string", resulting in a steadily
> deteriorating transfer rate, at least up to some point at which the HP-48
> dumps the string to storage and starts over with a new string. There's not
> much that the Kermit client can do about that.
Actually, it has to copy the *entire* received buffer for each packet,
from what I understand.
> Any other hints from HP-48 users will be appreciated; I'll be glad to
> collect them into an FAQ.
The '48 is very picky about some aspects of the Kermit protocol. Here are
a few additional points about the HP48's server:
- The only way to change the working directory is with a command packet
that reads: { Relative_directory_name } EVAL
- Each command packet will send back data containing a stack dump.
- Directory dumps are in the format:
---
{ Current_directory } Free_space
Object_name Object_size_bytes Object_type Object_CRC
... etc ...
---
- Error packets should contain CR+LF (#M#J) at the end of the string
- You can shut the HP48's server down with a 'G' packet, data "F"
/\/\att /\/\astracci mmastrac@acs.ucalgary.ca
"Tout choses sont dites deja, mais comme personne n'ecoute, il faut
toujours recommencer."